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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

In today's world there are many different types of messaging services available both in the wired and wireless worlds. 
Some messaging services are supported in both environments; others are only to be found in one. The expectations of 
the services differ in that some are designed to be used in what is perceived as 'real' time, whereas others are designed 
as a 'mailbox' service where the message is stored ready for collection or delivery at a later stage. 

The 3GPP Technical Report TR22.940 identifies the issues and needs surrounding messaging solutions related to the 
3GPP IP Multimedia Subsystem (IMS) taking into consideration use cases that illustrate the needs of both service 
providers and users. This Technical Specification takes the Technical Report into account when defining the 
requirements for the support of IMS Messaging. 

IMS Messaging services incorporates one or more of the following messaging types Immediate messaging and Session 
based messaging. With Immediate messaging the sender expects immediate message delivery in what is perceived as 
real time. With Session based messaging a communications association is established between two or more users before 
communication can take place. In the simplest form Session based messaging maybe a direct communication between 
two users. This specification defines the requirements for both the Immediate message type and the Session based 
message type. 

The specification provides the ability to develop interoperable messaging services that use Immediate and/or Session 
based message types. 



ETSI 



3GPP TS 22.340 version 1 0.0.0 Release 1 5 ETSI TS 1 22 340 V1 0.0.0 (201 1 -04) 



Scope 



The present document specifies the stage one description of the IMS Messaging services. Stage one is an overall service 
description and defines service requirements, primarily from the subscriber's and service providers' points of view, and 
does not deal with the details of the human interface itself. 

The present TS includes information applicable to network operators, service providers and terminal, switch and 
database manufacturers. 

The present TS contains the requirements for IMS Messaging services, which are sufficient to provide a complete 
service. The messaging types identified in this document are: immediate messaging and session based messaging. 

It is highly desirable that technical solutions for IMS Messaging services should be sufficiently flexible to allow for 
possible enhancements. Additional functionalities not documented in this 3 GPP TS may implement requirements which 
are considered outside the scope of this 3GPP TS. Such additional functionality shall not compromise conformance to 
the core requirements of the service. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] Void 

[2] 3GPP TS 22.250: 3^^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; Stage 1, IMS Group Management 

[3] RFC 2486: "The Network Access Identifier" 

[4] 3GPP TS 21.133; 3^^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; 3G Security; Security Threats and Requirements 

[5] 3GPP TS 26.140; 3^^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; Multimedia Messaging Service (MMS); Media formats and codecs 

[6] 3GPP TS 26.234: "End-to-end transparent streaming Service (PSS); Protocols and Codecs". 

[7] 3GPP TS 22.228; 3^^ Generation Partnership Project; Technical Specification Group Services and 

System Aspects; Service requirements for the Internet Protocol (IP) multimedia core network 
subsystem; Stage 1 

[8] 3GPP TS 26.244: "Transparent end-to-end packet switched streaming service (PSS); 3GPP file 

format (3GP)'; 

[9] 3GPP TS 26.245: "Transparent end-to-end packet switched streaming service (PSS); Timed text 

format'. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

Immediate messaging: A type of IMS Messaging service by which the sender expects immediate message deUvery in 
(near) real time fashion 

IMS Messaging services: A group of services, supported by capabiHties of the 3GPP IP Multimedia Subsystem 3GPP 
TS 22.228 [7], that allows an IMS user to send and receive messages to other users. IMS messaging services comprise 
of one or more types: Inmiediate messaging and Session based messaging. 

Session based messaging: A type of IMS Messaging service by which the sender expects immediate message delivery 
in (near) real time fashion . In addition the sender(s) and the receiver(s) have to join to a messaging session e.g. chat 
room, before message exchange can take place 

3.2 Abbreviations 

IP Internet Protocol 

IMS IP Multimedia Subsystem 

OMA Open Mobile Alliance 
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4 Informative description of messaging services in the 

IIVIS 

As 3 GPP has developed the concept of IMS it is thought useful to consider how a SIP based IP network can be utilised 
to provide messaging capabilities. One of the chief characteristics of SIP is its ability to rapidly and efficiently create 
real-time sessions between groups of users. It therefore appears that SIP based messaging would be a potential 
candidate to provide the equivalent of 'Chat Room' and 'Instant Messaging' (IM) type services found on the Internet 
today. Typical characteristics instant messaging are instant delivery of the messages to the targeted recipient(s) and 
interaction with presence information where users are able to see who is on-line as well as their status. 

A chat room is a "place" where multiple persons can join, follow and contribute to the ongoing discussion and leave the 
"room" at any time. Chat rooms are more permanent in nature when compared to IM exchanges and may be created by 
users or service providers. Additionally, chat rooms can be further divided to the private and public chat rooms. 
Normally, users who are participating in chat room will receive all the messages that are sent by the other participants. 
Similarly, the users are also able to send private messages to the chat room or even privately to some participant. 

Unfortunately, the most popular internet based instant messaging services are usually based upon closed and proprietary 
protocols which has made it impossible for different service providers to allow interoperable messaging between their 
respective users. Additionally, internet based services do not take into consideration the wireless environment and the 
needs of operators to provide services that are commercially viable by for example, providing support for charging. This 
technical specification will further elaborate the essential messaging characteristic of these services and state how they 
may be enhanced, e.g. operators may be able to create and then advertise chat rooms containing specific content where 
users who join the room may be charged an 'entrance' fee. 



Join to chat 




Amanda 

Figure 1. Example IMS Messaging service: Chat room 
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5 Informative description of messaging types 

Messaging can be divided to two different main classes based on the expectation of the sender. The sender either 
expects the message to be dehvered immediately or he does not care so much whether the message is delivered 
immediately or later. 

The immediate case can be further divided to two different sub-classes based on the actions required form the user 
before he can engage in a communication. The user can both send and receive messages without any prior actions or he 
may be required to join to a messaging session before the message exchange can take place. 

The messaging types considered in this specification are 

- Immediate messaging: 

Typically, sender is aware of the availability of the recipient(s) (possibly through the use of the Presence service) 
before sending this type of message as, if the recipient is not available, the message may be discarded or 
deferred. An immediate message may be deferred by the recipient's network based on the message filtering 
settings defined by the recipient or by the recipient's IMS service provider. 

- Session based messaging: 

The sender and recipient expect near real time message delivery. Typically, recipients of the session based 
messaging that are not joined to a group or are not available will not receive the messages. Typically, a sender 
may send a message to all participants in the messaging session without addressing them individually. 



6 Immediate messaging requirements 

6.1 General requirements 

Network operators have different network configuration and commercial requirements. IMS Messaging shall be 
supported in a manner that meets the operator's IMS requirements. Thus, an identified set of functionalities and formats 
shall be standardized to ensure interoperability across networks and terminals to support IMS Messaging. 

The following general requirements shall be supported by Immediate messaging. 

a) It shall be possible for the UE and the network to differentiate between immediate messages from other 
messaging types. 

b) Within the capabilities of networks and terminals, the user shall have a consistent experience regardless of the 
access network e.g. 3GPP systems, fixed networks, the Internet. 

c) Immediate messaging shall support a minimum set of functionality for message delivery, management and 
filtering to ensure interoperability between different terminals and networks. 

d) Immediate messaging shall be able to support the ability of the recipient's network to take into account the 
recipient's terminal capabilities. In addition, the originating network/terminal may also be able to take into 
account recipient's terminal capabilities. Specifically the recipient's terminal capabilities that may be taken into 
account at a minimum include: 

1) Display capabilities (including screen size, number of colours, number of lines of text, etc); 

2) Media content types supported (Audio, Video etc); 

3) Media content formats supported (JPEG, GIF, etc); 

4) Media Storage capacity; 

5) Encryption/Security mechanisms supported 

The capabilities of the user's terminal may be reflected in the message filtering and corresponding actions as 
identified in clause 6.7. 
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e) Immediate messaging should be able to take into account the availability and changes of the state of availability 
of the terminal. Immediate messaging shall be able to make use of the Presence Service, if provided by the 
network. 

f) It shall be possible to store in the ISIM a number of sets of configuration information to allow access to 
Immediate messaging services. One of these sets of configuration information is preset by the issuer of the ISIM. 
Such preset configuration information set shall only be configurable by issuer of the ISIM. The preset 
configuration information is selected unless otherwise specified by the user. It shall be possible to retain the 
configuration information when the UICC is used in different terminals. 

g) It shall be possible to send and receive immediate messages without prior establishing a messaging session. 

h) It shall be possible for the network operator providing the Immediate messaging service to choose, wherever 
possible, the most suitable transport mechanism for carrying messages (e.g. signalling network, dedicated PDP 
context, other access technologies and so on. . .) both for UE originated and UE terminated messages. 

i) It shall be possible for the network operator providing the Immediate messaging service to choose, wherever 
possible, the parameters used (i.e. QoS) both for UE originated and UE terminated messages. 

6.2 Message content requirements 

Following requirements are specific to content delivered with immediate messaging. 

a) Content size shall not be limited by technology. 

b) It shall be possible to carry different media including text, images, video and audio within a single message. 
Media types shall be MIME encoded. 

c) Immediate messaging shall provide a minimum set of supported formats to ensure full interoperability between 
different terminals and networks (e.g. JPEG for pictures, AMR for speech, H.263 for video). The minimum set 
of supported formats shall be common to all IMS Messaging types. The minimum set of supported formats 
should be aligned with formats used in other 3GPP-defined services 3GPP TS 26.140 [5], 3GPP TS 26.234 [6]. 

d) Content formats shall be defined so that interworking with 3GPP and Internet messaging solutions is facilitated. 

e) It shall be possible to compose message of either a single medium (e.g. voice) or multi-media (e.g. voice and 
video). The IMS Messaging service shall be able to support a request for media sequencing. 

6.3 Management requirements 

The following management requirements shall be supported. 

a) The IMS service provider shall be able to enable/disable message delivery and submission. 

b) Immediate messaging shall be able to support a request from the user to enable/disable message delivery. 

c) Immediate messaging shall be able to support the user to manage his user service profile related to Immediate 
messaging (e.g. customize his messaging environment within the capabilities of the terminal, network and 
messaging application). This could be unconditional or conditional e.g. depending on roaming conditions or 
operator restrictions. 

d) Immediate messaging shall allow an IMS service provider to configure Immediate messaging environment e.g. 
in such a way that submitted and/or incoming Immediate messages of a particular user are stored in a network 
based repository. 

6.4 Message delivery requirements 

Following requirements define the message delivery. 

a) Message delivery shall be immediate i.e. messages are transported by the IMS system to the recipient's terminal 
(without notifications) subject to message filtering settings defined by the recipient or by the recipient's IMS 
service provider. 
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b) Messages shall not be stored by the network. If supported by the recipient's network as an application option 
messages may be stored in the recipients network. 

c) It shall be possible for the sender to receive delivery acknowledgements (success/failure) for sent messages. 

6.5 Storage requirements 

The following storage requirements shall be supported. 

a) It shall be possible for a sender to request to persistently store a sent Immediate message in a network based 
repository at the time of sending if the IMS service provider provides such application level service. 

b) Immediate messaging shall be able to support a request from a user to retrieve messages that are stored in a 
network based repository. 

c) Immediate messaging shall be able to support a request from a user to delete messages that are stored in a 
network based repository. 

d) Immediate messaging shall be able to support a request from a user to forward one or more messages that are 
stored in a network based repository to another destination. 

e) Immediate messaging shall be able to support a request from a user to view the list of messages and message 
related attributes, such as sender, recipient, subject and date/time, in a network based repository. 

f) Immediate messaging shall be able to support a request from a user to upload one or more Immediate messages 
into a network based repository for persistent storage. 

6.6 User privacy requirements 

Following requirements define user privacy. 

a) It shall be possible for the recipient to see the public ID of the sender of the message unless the sender has 
requested to hide it. 

b) It shall be possible for the sender of the message to request to hide its public ID from the recipient (anonymous 
sender). 

The sender's public ID shall not be delivered to the recipient. The capability of public ID hiding is an IMS 
service provider and legislation issue and it may or may not be available. If the service is not available the 
message shall not be delivered to the recipient. 



6.7 Message Filtering 



It shall be possible for a subscriber to set up, modify, and delete filters in the network of the subscriber's IMS service 
provider, in order to control the treatment of a message by the network when an immediate message is received when 
the subscriber is either unavailable or when the subscriber does not currently want to receive messages. The filters shall 
also support the ability of the subscriber to specify the maximum size and type of message content etc that they are or 
are not willing to accept. The filters shall also support the ability of the subscriber to block (and unblock) messages 
from specific senders or anonymous senders. 

Following specific requirements define the message filtering capabilities of the recipient. 

a) It shall be possible to define specific message treatment based on following criteria 

1) sender address (including anonymous senders); 

2) message size; 

3) message class (e.g. advertisement, private. . ..); 

4) message priority; 

5) message content type (e.g. video, audio. . ..); 
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6) message content format (e.g. mpeg, jpeg. . . .); 

7) message type (e.g. immediate message); 

8) message subject; 

9) availability of the recipient; and 

10) additional criteria maybe possible but are outside the scope of this document., 
b) It shall be possible to specify the following message treatments in a filter: 

1) Block the delivery of the message content. 

2) Store the message content and notify recipient. 

3) Store the message content for a specific time or until the recipient requests delivery. 

4) Store and push the message content to recipient when available. 

5) Redirect the message to another address. 

6) Additional treatments maybe possible but are outside the scope of this document. 

The IMS service provider shall also be able to set and control the filter settings either on behalf of the subscriber or 
based on policy. 

7 Session based messaging requirements 



7.1 General requirements 



Network operators have different network configuration and commercial requirements. IMS Messaging shall be 
supported in a manner that meets the operator's IMS requirements. Thus, an identified set of functionalities and formats 
shall be standardized to ensure interoperability across networks and terminals to support IMS Messaging. 

The following general requirements shall be supported. 

a) There shall be a mechanism to differentiate session based messages from other messaging types. 

b) Within the capabilities of networks and terminals, the user shall have a consistent experience regardless of the 
access network e.g. 3GPP systems, fixed networks, the Internet. 

c) Session based messaging shall support a minimum set of functionality to ensure interoperability between 
different terminals and networks. 

d) Session based messaging shall be able to take into account the capabilities of the terminals participating in the 
messaging session. Specifically the terminal capabilities that may be taken into account at a minimum include: 

1) Display capabilities (including screen size, number of colours, number of lines of text, etc); 

2) Media content types supported (Audio, Video etc); 

3) Media content formats supported (JPEG, GIF, etc); 

4) Media Storage capacity; 

5) Encryption/Security mechanisms supported 

The capabilities of the user's terminal may be reflected in the message filtering and corresponding actions as 
identified in clause 7.7. 

e) It shall be possible to store in the ISIM a number of sets of configuration information to allow access to IMS 
Messaging services. One of these sets of configuration information is preset by the issuer of the ISIM. Such 
preset configuration information set shall only be configurable by issuer of the ISIM. The preset configuration 
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information is selected unless otherwise specified by the user. It shall be possible to retain the configuration 
information when the UICC is used in different terminals. 

f) It shall be possible for the subscribers to join to a session e.g. chat room. 

g) It shall be possible for the subscribers to leave a session e.g. chat room. 

h) It shall be possible to send a message to all the participants of a messaging session without specifying the 
individual participant's addresses or using a message delivery list. 

i) It shall be possible to invite new participants to the existing messaging session. 

1) The invitations shall be semi permanent i.e. it is not required that invitee will act immediately. 

2) It shall be possible to cancel the invitation by the inviter. 

3) It shall be possible for the inviter to define the validity period of the invitation. 

4) It shall be possible for the invitee to see the originator of the invitation unless the inviter has required hiding 
his public ID. 

5) It shall be possible for the inviter to define the messaging session to which the invitation is made. 

6) It shall be possible for the invitee to identify the messaging session to which he was invited. 

j) It shall be possible for the recipient of the message to identify from which messaging session the message came 
from (for both public and private messages). 

k) It shall be possible for the recipient to identify the sender (unless the sender has required hiding its public ID) of 
the message in addition to the messaging session from which the message came from. 

1) It shall be possible for the sender to send a private message for a selected recipient. 

m) It shall be possible for the recipient to determine if the message was send as a private message within a 
messaging session. 

n) It shall be possible for the subscriber to request the message session properties e.g. list of active members. 

o) It shall be possible for the subscriber to automatically receive updates containing the changes in message session 
properties e.g. change in the list of active members. 

p) It shall be possible to utilize IMS Group Management 3GPP TS 22.250 [2] as appropriate. 

q) It shall be possible for a subscriber in an IMS Messaging session to request and to receive an indication of when 
user is entering a message ('Is typing'). This request may apply to a specific user or users in the same session. 
Subject to privacy requirements, the corresponding indications will identify the persons who are entering a 
message. 

r) It shall be possible for the network operator providing the IMS Messaging service to choose, wherever possible, 
the most suitable transport mechanism for carrying messages (e.g. signalling network, dedicated PDP context, 
other access technologies and so on. . .) 

s) It shall be possible for the network operator providing the IMS Messaging service to choose, wherever possible, 
the parameters used (i.e. QoS) 

t) The operator shall be able to enforce the use of the preferred transport mechanism and parameters both for UE 
originated and UE terminated messages. 

7.2 Message content requirements 

Following requirements are specific to content delivered with session based messaging. 

a) Content size shall not be limited by technology. 

b) It shall be possible to carry different media including text, images, video and audio. Media types shall be MIME 
encoded. 
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c) Session based messaging shall provide a minimum set of supported formats to ensure full interoperability 
between different terminals and networks (e.g. JPEG for pictures, AMR for speech, H.263 for video). The 
minimum set of supported formats shall be common to all IMS Messaging types. The minimum set of supported 
formats should be ahgned with formats used in other 3GPP-defined services 3GPP TS 26.140 [5], 3GPP TS 
26.234 [6]. 

d) Content formats shall be defined so that they enable interworking with 3 GPP and Internet messaging solutions. 

e) It shall be possible to compose message of either a single medium (e.g. voice) or multi-media (e.g. voice and 
video). The IMS Messaging service shall be able to support a request for media sequencing. 

7.3 Management requirements 

The following management requirements shall be supported. 

a) IMS Messaging shall be able to support a request from the IMS service provider to enable/disable message 
delivery and submission. 

b) IMS Messaging shall be able to support a request from the user to enable/disable message delivery and 
submission. 

c) IMS Messaging shall be able to support the user to manage his user service profile related to IMS Messaging 
(e.g. customize his messaging environment within the capabilities of the terminal, network and messaging 
application). This could be unconditional or conditional e.g. depending on roaming conditions or operator 
restrictions. 

d) It shall be possible for IMS service provider to configure messaging session environment e.g. in such a way that 
all incoming IMS Messages are stored in a network based repository. 

e) It shall be possible for an authorized user or an IMS service provider enable session based messaging (e.g. create 
chat room) and thus become an administrator of messaging session. 

f) It shall be possible for the administrator of a messaging session to control who is allowed to participate in the 
messaging session. 

g) It shall be possible for the IMS service provider or administrator of a messaging session to disable messaging 
session (e.g. close a chat room). 

h) It shall be possible for the administrator of the messaging session (to set properties related to the messaging 
session (e.g. the chat room name, topic, maximum number of active users). 

7.4 Message delivery requirements 

Following requirements define the message delivery. 

a) Message delivery shall be immediate i.e. messages are transported by the IMS system to the recipient's terminal 
(without notifications) subject to message filtering settings defined by the recipient or by the recipient's IMS 
service provider. 

b) It shall be possible for the sender to receive delivery acknowledgements (success/failure) for sent messages. 



7.5 Storage requirements 



Session Based Messaging shall support global storage of sessions (accessible to all participants) and personal storage 
(accessible to the user who requested the storage). For personal storage, all storage operations listed below are 
applicable. In the case of global storage, users will be able to list and retrieve messages, not delete messages or turn 
storage on or off. 
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The following storage requirements shall be supported. 

a) It shall be possible for a participant to request to persistently store a sent Session Based Message or all messages 
associated with a session in a network based repository if the IMS service provider provides such application 
level service. 

b) IMS Messaging shall be able to support a request from a user to retrieve one or more messages stored in a 
network based repository. 

c) IMS Messaging shall be able to support a request from a user to delete one or more messages or sessions that are 
stored in a network based repository. 

d) IMS Messaging shall be able to support a request from a user to view the list of messages and message related 
attributes, such as sender, recipient, subject and date/time, in a network based repository. 

7.6 User privacy requirements 

Following requirements define user privacy. 

a) It shall be possible for the recipient to see the public ID of the sender of the message unless the sender has 
requested to hide it. 

b) It shall be possible for the sender of the message to request to hide its public ID from the recipient (anonymous 
sender). 

The sender's public ID shall not be delivered to the recipient. The capability of public ID hiding is an IMS 
service provider and legislation issue and it may or may not be available. If the service is not available the 
message shall not be delivered to the recipient. 

c) It shall be possible for the sender to use nickname when sending messages. 

In case of nickname the recipient shall only be able to see the nickname but not the real address from which the 
message came from. It shall be possible to use nicknames for public and private messages. It shall be possible for 
the recipient to reply to the message sent with a nickname. 

d) It shall be possible for a member of an IMS Messaging session to disable the reporting of the indication that they 
are entering a message ('Is Typing') on a per session basis. Further granularity levels for this requirement is for 
further study. 



7.7 Message Filtering 



It shall be possible for a subscriber to set up, modify, and delete filters in the network of the subscriber's IMS service 
provider, in order to control the treatment of a message by the network when a message is received. The filters shall 
also support the ability of the subscriber to specify the maximum size and type of message content etc that they are or 
are not willing to accept. The filters shall also support the ability of the subscriber to block (and unblock) messages 
from specific senders or anonymous senders. 

Following specific requirements define the message filtering capabilities of the recipient. 

a) It shall be possible to define specific message treatment based on following criteria 

1) sender address (including anonymous senders); 

2) message size; 

3) message class (e.g. advertisement, private. . ..); 

4) message priority; 

5) message content type (e.g. video, audio. . ..); 

6) message content format (e.g. mpeg, jpeg. . . .); 

7) message type (e.g. immediate message); 

8) message subject; and 
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9) additional criteria maybe possible but are outside the scope of this document, 
b) It shall be possible to specify the following message treatments in a filter: 

1) Block the delivery of the message content. 

2) Store the message content and notify recipient, 

3) Store the message content for a specific time or until the recipient requests delivery. 

4) Store and push the message content to recipient when available. 

5) Redirect the message to another address. 

6) Additional treatments maybe possible but are outside the scope of this document. 

The IMS service provider shall also be able to set and control the filter settings either on behalf of the subscriber or 
based on policy. 



8 Addressing requirements 



It shall be possible to use a single address to identify the recipient. The single address shall be either a SIP URL, a 
network address identifier (NAI as defined in RFC2486 [3]) or a MSISDN. 

IMS Messaging shall be based on existing IMS address resolution and routing mechanisms. 



Security 



The user shall be able to use IMS Messaging and access messages in a secure manner. It shall be possible for the 
contents of messages to be read only by the intended recipient(s). A recipient shall be informed of the reliability of the 
identity of the sender in case the sender has authorised his identity to be transmitted. 

The integrity of messages during transit shall be assured to extent of the network capabilities. 

IMS Messaging shall be intrinsically resistant to attempts of malicious or fraudulent use. 

The "Security Threats and Requirements" specified in 3GPP TS 21.133 [4] shall not be compromised. 

10 Charging 

Charging for IMS Messaging shall be based on existing IMS charging mechanisms as appropriate. 
IMS Messaging shall be able to support various charging models, including: 

a) sender only pays; 

b) both sender and recipient pay their respective charges for message delivery; and 

c) recipient pays. 

IMS Messaging shall be able to support different charging approaches: 

a) volume based charging; 

b) QoS based charging; 

c) service based charging; 

d) number of messages sent and/or received; and 

e) offline charging or/and online charging. 
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IMS Messaging shall be able to support various charging mechanisms. The following charging characteristics may be 
considered: 

a) message content type and length; 

Message content type should be declared using a standardised declaration [the note may need to be moved to a 
different section e.g. message filtering]. 

b) roaming conditions; 

c) prepaid subscriptions; 

d) time when the message is sent; 

e) time when the message is delivered; 

[FFS, 'delivered' could indicate message stored, message read, message received by the terminal and so on. . .] 

f) message origin and destination; 

g) access network employed; and 

h) the charging information shall describe the amount of data sent and received to and from the external data 
network [Note: this is introduced to take into account the network(s) transited by message]. 



11 Interworking 

11.1 General 

It should be possible for the IMS Messaging subscriber to send/receive messages to/ from subscribers of 3GPP defined 
messaging services (SMS, EMS, MMS). Optionally, it should be possible to send/receive messages to/from users of 
fixed Internet messaging service (e.g. SMTP and SIMPLE based services). 

1 1 .2 Requirements for SMS-lmmediate Messaging service-level 
interworking 

These requirements shall be considered for SMS-lmmediate Messaging service-level interworking: 

- it shall be possible for a user to send an Immediate Message or an SMS message to another user without having 
to know which messaging client the receiving user has; 

- The user experience shall be consistent with the SMS and Immediate Messaging service level expectations to as 
large an extent as possible. If the recipient is not available and deferred messaging is offered then the message 
shall be kept until delivery is possible or the message expires; 

- When interworking from an SMS message to an Immediate Message, the network should deliver all content 
types in an SMS message to equivalent IMS content types where they exist; 

- When interworking from an Immediate Message to an SMS message, the network should deliver all content 
types in an Immediate Message to equivalent SMS content types where they exist; 

- When interworking from an Immediate Message to an SMS message and a form of anonymity has been 
requested by the sending party and the operator of the interworking function cannot identify the sending party, 
subject to operator policy, interworking shall be suppressed for that message. Subject to operator policy and / or 
the ability to identify the sending party, the sending party may be informed that the message could not be 
delivered. 

- When interworking from an Immediate Message to an SMS message, it shall be possible for the sender of the 
Immediate message to request to hide its public ID from the recipient (e.g. be an anonymous sender). In this 
case the sender's public ID may not be delivered to the recipient subject to operator policy. 
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- Based on operator policy, it shall be possible for e.g., an SMS system or data download message such as an over 
the air configuration message, to be prevented from being interworked at a service level to an Immediate 
Message, but to instead by transported as an SMS message via IMS, CS or PS; 

- If a user is registered to receive SMS service, then the SMS message should be delivered as an SMS message via 
IMS, CS or PS transport instead of via service-level interworking, subject to operator and user preferences; 

- If a user is registered to receive Immediate Messaging service, then the Immediate Message should be delivered 
that way instead of via service-level interworking, subject to operator and user preferences; 

- If an SMS user requests an SMS status report, then an SMS status report should be generated when the message 
is delivered using Immediate Messaging; 

- If an IMS user requests a notification that the message was delivered to the recipient, an SMS status report 
should be generated when the message is delivered to the SMS user"s client; 

- It shall be possible to generate the appropriate charging-related information and provide the appropriate online 
charging mechanism (if it is applied for the SMS and/or Immediate Messaging services) for the interworking 
services. 

1 1 .3 Requirements for SMS-Session based Messaging service- 
level interworking 

These requirements shall be considered for SMS-Session based messaging service-level interworking: 

Pre Release 10 UE shall be supported by SMS-Session based messaging service-level interworking. 

it shall be possible for a session based messaging user to send a messaging session invitation to an SMS user; 

When interworking from a Session based message to an SMS message, the network should deliver all content 
types in the Session based message to equivalent SMS content types where they exist; 

When interworking from an SMS message to a Session based message, the network should deliver all content 
types in an SMS message to equivalent Session based message content types where they exist; 

If an SMS user requests an SMS status report, then an SMS status report should be generated when the message 
is delivered using Session based message and a success or failure delivery notification has been received from 
the Session based message user; 

If a Session based message user requests a notification that the message was delivered to the recipient, an SMS 
status report should be generated when the message is delivered to the SMS user"s client; an SMS status report 
should be communicated to a Session based message user as a delivery notification; 

A session invitation sent towards an SMS user is handled in one of 3 ways (dependent on service provider 
policies): 

1) The session invitation is accepted by the network on behalf of the SMS user. 

2) The session invitation is denied by the network on behalf of the SMS user. 

3) The SMS user is asked for consent for accepting the session invitation: 

- The session invitation will be delivered as an SMS message to the SMS user; the appropriate instructions 
should be included to guide the SMS user how to react (join/reject) the session invitation. 

- The SMS user will send back a response in an SMS message according to the embedded instruction if 
included. 

The user experience shall be consistent with the SMS and Session based messaging service level expectations to 
as large an extent as possible; 

For session based messaging the session based connectivity should be maintained for the SMS user so that the 
SMS user could: 
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- participate in the session (i.e. exchange messages) 

- exit the session (no more message exchange) according to the instruction embedded in the SMS message. 

When interworking a session invitation from a Session based messaging service to an SMS message and a form 
of anonymity has been requested by the sending party and the operator of the interworking function cannot 
identify the sending party, subject to operator poHcy, interworking shall be suppressed for that session invitation. 
Subject to operator policy and / or the ability to identify the sending party, the sending party may be informed 
that the session invitation could not be delivered. 

- When interworking a session invitation from a Session based messaging service to an SMS message, it shall be 
possible for the sender of the session invitation to request to hide its public ID from the recipient (e.g. be an 
anonymous sender). In this case the sender's public ID shall not be delivered to the recipient subject to operator 
policy. 

It shall be possible to generate the appropriate charging-related information and provide the appropriate online 
charging mechanism (if it is applied for the SMS and/or Session based messaging services) for the interworking 
services. Such charging related information shall take into account the one-to-many relationship of messages 
sent to a session. 
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